home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / transcript_1108 / text0035.txt < prev    next >
Encoding:
Text File  |  1995-11-26  |  5.0 KB  |  114 lines
  1. Hi everyone,
  2.  
  3. I thought I would send this message to the mailinglist as it may be of
  4. interest to you all. It's from a discussion I and Doug have, and I don't think
  5. he would mind if I send it to you all. Ignore my stupied questions as I know 
  6. as much about 3D graphics like a frog, but the anwers might be of interest.
  7.  
  8. I can also add from another letter I received from Doug that when he had
  9. recoded 60% of the code he hade increased the speed with around a factor 3.
  10. But as he says in this letter he have found some problems.
  11.  
  12.  >> e> Have you tried the program? It will work with the demo version
  13.  >> e> WAD of Doom I. It's not fast, but quite nice. :-)
  14.  >> 
  15.  
  16.  >> Not only tried it, but rewritten most of it too. Very crap code 
  17.  >> horrible to read and slow ashell. 
  18.  
  19.  e> :-) I have been talking to Laurent, and it is like you said
  20.  e> disassembled c-code, but the most part is rewritten and alot of it is
  21.  e> not used at all. Laurent only "forgot" to delete it. He have also done
  22.  e> a new version with only assembler code and deleted all the old c-code,
  23.  e> but you have already done that.
  24.  
  25. Yes, but I have discovered a more serious problem - the optimisations they 
  26. have made have damaged the printing order to the point where you get bits 
  27. of 'floor' in the 'roof' and vice versa - but only in very specific places. 
  28. I will have to reverse-engineer this and get the algorithm back in working 
  29. order before I can continue speeding it up - most of the optimisations made 
  30. so far (but not all) have been trivial and are not going to boost the speed 
  31. by much. It needs rebuilt from the gound up.
  32.  
  33. I still don't think I have anything close to a recent version, but it 
  34. doesn't matter now since we have solved most of the puzzles - and we can 
  35. rebuild from this data. Thanks for the textfiles! They were useful!
  36.  
  37.  >> A lot of work needs to be done, but it's just possible we can get it
  38.  >> going fast! :)
  39.  
  40.  e> YESSS, this is what I want to hear!!! YYYEEESSS!!!! Have you speeded
  41.  e> it up anything already? I want to know! :-)
  42.  
  43. Yes, but we had to stop this when we realised that some of the previous 
  44. optimisations had damaged the drawing process. I'm trying to fix this right 
  45. now.
  46.  
  47.  >> One serious problem though - all the coordinates are integer-based.
  48.  >> This means low accuracy, and the texturemapping will suffer when it is
  49.  >> put in.
  50.  >> I will need to replace all the 16-bit integer maths with fixed-point 32-
  51.  >> bit stuff. I also fixed a hell of a lot of bugs caused when they converted
  52.  >> the 'C' to assembly - which caused garbage to appear in certain rooms
  53.  >> with large WAD files.
  54.  
  55.  >> :-) Great! Will the 32 bit integer stuff slow down the game? Isn't it
  56.  >> going to be faster with just 16 bit?
  57.  
  58. No - with 3D, things don't work like that. The idea is that you increase 
  59. the amount of arithmetic and mathematical routines (making it a little bit 
  60. slower as a result) in order to make more exhaustive calculations - which 
  61. increases visual accuracy and lets you make highly accurate decisions about 
  62. what you can discard (the stuff you can't see directly in front of you). 
  63. This makes it MUCH MUCH faster than any optimisation can 
  64. achieve.
  65.  
  66. One of the optimisations I have made is checking to see of a 'node' (a 
  67. 'sector' or 'sub-room' - like a doorpost etc.) is hidden behind a door, 
  68. wall or object, and then discarding that entire part of the BSP tree, as 
  69. anything 'inside' the 'node' must be invisible if the node ITSELF is 
  70. invisible. This makes a huge difference in corridors and rooms (as it 
  71. doesn't then calculate stuff behind solid walls), and doesn't take very 
  72. long to do.
  73.  
  74. This is what I was trying to explain to Laurent - optimising assembly can 
  75. be damaging on it's own (makes things harder to modify later) and doesn't 
  76. offer great rewards in speed. You must first develop a system that is 
  77. PROCEDURALLY fast - then optimise when you are happy with it.
  78.  
  79. I don't think Laurent believes that this approach is worth very much, as he 
  80. is used to writing demos and stuff in assembly, and isn't much interested 
  81. in algorithms - but I have used both for quite some time now - and I do get 
  82. good results from better algorithms.
  83.  
  84. The layout of the program is also all wrong - the 68030 cache is not being 
  85. used at all and that is going to make things half as fast as they could be 
  86. straight away!
  87.  
  88.  >> Anyway, I'd better get back to it, as there's much to do... 
  89.  
  90.  e> Heh... keep coding, but don't kill your self. :-) You are to much
  91.  e> needed for that. :-)
  92.  
  93. I have to do as much as possible just now, as I might not get much time on 
  94. it later - I have Apex 3 to work on and the game still needs finished off 
  95. very soon.
  96.  
  97.  >> Bye! 
  98.  
  99.  e> Bye! I will love this!!! :-)
  100.  
  101. I hope so - the program is behaving a lot better now, but could still be 
  102. made a lot faster!
  103.  
  104. Doug.
  105.  
  106. ┌───────────────────────────────────────────────────────────────────────┐
  107. │  Black Scorpion Software Developments   ≡≡≡≡≡≡≡   Falcon030 & Jaguar  
  108. │
  109. ├───────────────────────────────────────────────────────────────────────┤
  110. │  Doug Little   ≡   Neil Stewart   ≡   Nick Hesketh   ≡   Dave Encill  
  111. │
  112. └───────────────────────────────────────────────────────────────────────┘
  113.  
  114.